Prepared statements#23156
Conversation
b9fbbae to
22f869e
Compare
688c58b to
2b65826
Compare
95c0aed to
9b9c0cd
Compare
f833f2f to
6c98d07
Compare
374aae7 to
9117f26
Compare
9117f26 to
5f730a1
Compare
cedric-anne
left a comment
There was a problem hiding this comment.
The proposed way to migrate to prepared queries is globally OK for me.
| * @param string $expression The query expression | ||
| * @param ?string $alias The query expression alias | ||
| */ | ||
| public function __construct($expression, ?string $alias = null) |
There was a problem hiding this comment.
It may help to produce less verbose code, for instance new QueryExpression('IF(field, ?, ?)', values: ['foo', 'bar'], alias: 'whatever').
| public function __construct($expression, ?string $alias = null, array $values = []) |
| }; | ||
| $func_name = strtoupper($func_name); | ||
| return self::getExpression($func_name, $params, $args[1] ?? null); | ||
| //FIXME: no idea how to handle possible statement values, and even if there are some... |
There was a problem hiding this comment.
I think we should not try to handle them. I even think we should deprecate this magic method, and declare simple static methods that corresponds to used functions. Anyway, it is out of the scope of this PR.
| ] | ||
| ); | ||
| } catch (StatementException $e) { | ||
| if (!str_contains($e->getMessage(), 'Duplicate entry')) { |
There was a problem hiding this comment.
A Duplicate entry is unexpected here, since dusplicates are supposed to be cleaned on lines 1100-1102.
|
|
||
| $this->expectExceptionMessage( | ||
| '`Computer::getFromDBByRequest()` expects to get one result, 2 found in query "SELECT `glpi_computers`.* FROM `glpi_computers` WHERE `contact` = \'johndoe\'".' | ||
| '`Computer::getFromDBByRequest()` expects to get one result, 2 found in query "SELECT `glpi_computers`.* FROM `glpi_computers` WHERE `contact` = ?".' |
There was a problem hiding this comment.
Is there a way to preserve values in the exception message ?
|
|
||
| namespace Glpi\DBAL; | ||
|
|
||
| abstract class Prepared |
There was a problem hiding this comment.
Maybe the names of the new classes could be more precise. For instance AbstractPreparedQuery, DeletePreparedQuery, ...
Rework affected rows (must be retrieved from statement) Handle Prepared from migrations Handle possible exisiting QueryExpression statement values Try to detect early bind issues Limit to simple cases for now Fix prepared IN, fix buildUpdate Try to get extra information on failure rawAnalyzeCrit (maybe to remove)
87349ba to
f84f3c7
Compare
WIP.
Currently, only "CRUD" related methods have been reworked; as well as DBIterator, and Query* classes.
Since Search engine relies on some f them but also have its own code; it's currently in a non working state. It's the next step; I began to work on this already.
HLAPI tests are also broken; I have no idea how to fix, nor if it's complex or not.
There also is a (minor) problem with 0.85 migration data. seems like the query and parameters are correct regarding sent criteria; and I've not been able to reproduce on my local instance (while I've spotted several other issues on that migration :/)